The present invention relates generally to computer networks, and more particularly to techniques for detecting the presence of aberrant code in a computer network.
The increasing reliance upon computer systems to collect, process, and analyze data makes computer network security and performance ever more important. One aspect of network security relates to what is referred to herein as “malicious code”—a set of computer instructions that perform a function unauthorized by the user. Malicious code appears in various forms, including viruses, worms, and Trojan horses. As used herein, the term “virus” refers to a computer program that can infect other computer programs by modifying them in such a way as to include a (possibly evolved) copy of itself, the term “worm” refers to a self-contained program that self-propagates and distributes complete (possibly modified) copies of itself without requiring a host program in order to survive, and the term “Trojan horse” refers to a complete computer program unto itself that purports to do one thing, but in reality does another and is usually consciously installed and launched by the unaware user. A Trojan horse can contain a worm or a program with a virus.
Malicious code typically exploits vulnerabilities in a network to self-propagate through the network to infect machines, or “nodes”, connected to the network, causing damage generated by the data payload and increasing the consumption of network bandwidth to the detriment of the performance of the network and infected network nodes in performing legitimate operations. Malicious code propagates most efficiently by attacking commonly used services on common network hosts. This means that, by definition, malicious code is traveling over the very services that most commonly appear on the network.
There are three basic techniques commonly available to detect the presence of malicious code propagating through a network, namely, “signature analysis”, “active host probing”, and “anomaly analysis”. Signature analysis is the most popular conventional approach to detecting malicious code and is based upon capturing and analyzing traffic and comparing it to known malicious code propagation signatures.
In order for signature analysis to be effective, malicious code must be rapidly detected and its signatures captured and distributed to the signature analysis systems remote sensors performing the analysis. However, the response time for discovering and distributing new signatures will always lag behind the introduction of new malicious code, often long after significant damage has already been done. Also, signature based systems require that traffic be captured and examined at the speed of the media for a match on a signature in the signature library, possibly archiving traffic when a signature match is triggered. This requires some substantial local processing power on Local Area Network (LAN) infrastructures and provides an incentive to deploy sensors only at the perimeter, and only over Wide Area Network (WAN) links, which are slower than LAN links due to typically slower instrumentation, higher traffic, and longer distance for transmission to destination.
The instrumentation required for signature analysis is dedicated, expensive, and should be carefully positioned and integrated to provide the maximum visibility through the enterprise without introducing single points of failure in the connectivity path. “Chokepoints” for network traffic are identified, but gaps in visibility can render the system ineffective. While this type of system is usually deployed at the perimeter of an enterprise network, malicious code is usually introduced into the enterprise from the interior, by mobile users, business partners, or remote access users. With sensors at the perimeter only, the first indication of malicious traffic may be as systems within the enterprise seek targets outside the network.
In active host probing, the host is directly probed or scanned to assess its security posture. More particularly, active host probes either query a client agent running on the host, or attempt to assess responses from direct communications with the host to determine whether it is vulnerable or not.
One form of active host probes are known as Network Access Control (NAC) systems. NAC systems function at the edge of the network, and work by initially limiting network access for a host that is connecting to the network. The NAC system queries a trusted agent on the host that reports on attributes like patch levels, virus definition versions, software firewall rules, etc. Only after comparing the results of the agent query to a network access policy of the local enterprise network may the host be permitted full connectivity to the network. If the host agent responds with inadequate patch levels or outdated virus scanning definitions, the NAC system can permit limited connectivity to the network to access remediation resources such as a patch repository, for example. Non-responsive hosts (e.g., hosts without a local agent) may be refused access, offered limited access, or probed directly for vulnerabilities.
In NAC systems, the network infrastructure includes a policy repository that is available for the entire enabled infrastructure. In addition, network compartments are defined throughout the enterprise to contain remediation resources, or to define limited, “guest” access. For a large, multi-site enterprise network, this is difficult and expensive to implement pervasively. Generally, it is recommended to be implemented in those areas of the topology at the greatest risk such as common “guest” areas, wireless networks, remote access infrastructure, or mobile “hot-desk” environments. A current policy (based upon known vulnerabilities) should be continually updated.
This system also only provides a snapshot of vulnerability assessment. Only when the host initially connects to the network is its security posture evaluated, and network access granted. Hosts which qualify for access today—and remain connected—might not remain compliant with the NAC policy, and could be compromised later with a novel infection. Thus, NAC systems offer only access control; and not ongoing continuous monitoring or evaluation. There is no guarantee that currently connected hosts will not become infected once connected.
There are, however, periodic scanning systems which search subnets, and probe hosts with test suites designed to indicate vulnerability. These systems must be updated with new test suites, also based upon known vulnerabilities, but the advantage is that they can operate continuously to identify newly infected already connected hosts. However, vulnerability scanning systems operate only to report vulnerable systems, and cannot isolate or remediate infected systems.
A third technique for detecting the presence of malicious code is referred to herein as “anomaly analysis”. In anomaly analysis, the behavior of the host on the network is analyzed to try to identify “unusual” traffic patterns that may indicate infection. Complete traffic data including entire conversation packets, connection setup packets, and flow data is collected to isolate conversations, which are then analyzed to detect anomalous connections or atypical bandwidth utilization that might indicate unknown attacks, insider misuse, worm propagation, or other malicious activity. Much of the existing work in network traffic anomaly detection revolves around identifying only one impact of malicious code—the consumption of unusually high network bandwidth. This is not a characteristic of all malicious code, but it is a relatively simple characteristic to detect. Other published algorithms for anomaly detection may include the analysis of connections to “unusual” destination ports, the analysis of attempted connections to systems that do not exist, and detection of protocol anomalies (i.e., traffic conversation behavior that may not be compliant with published specifications for a particular protocol). Clearly, the disadvantage of protocol anomaly detection is the requirement of pervasively deployed “promiscuous” instrumentation for decoding every packet in the conversation, which is very expensive.
Anomaly detection systems require pervasive and detailed traffic characterization information in order to construct a “normal” behavioral model. This presents many of the same problems that face signature based detection systems. In order to construct an accurate picture of traffic flows and volumes, collection devices are deployed through the network infrastructure. These devices are run at the speed of the media (i.e., keep up with high-speed LAN traffic without missing any packets), and an enormous volume of data must be rapidly correlated through the enterprise, eliminating duplicate conversations that may be visible to multiple collectors. Both near-real time data, and historical data should be available, to provide timely detection of new anomalies, and to support the analysis of unusual behaviors over extended periods of time.
Because it has been historically difficult to visualize enterprise-wide traffic flow information pervasively, it is difficult to identify and analyze patterns in the overall traffic conversation. The common approaches to anomaly analysis are plagued by high rates of false positives for detecting malicious code because they infer malicious behavior from indirect indications such as traffic volumes.
In summary, the above-identified techniques for detecting the presence of malicious code in nodes of an enterprise network have been limited by the technologies available for network monitoring. Historically available technologies have focused on detailed, promiscuous monitoring at specific chokepoints, and have generated extremely large data sets of monitoring information that are virtually impossible to correlate across an enterprise network.
Accordingly, a need exists for a technique for reliably separating and identifying malicious network code from benign, normal application code, and to do so without having to examine every packet transmitted in the network. Furthermore, a need exists for a malicious code detection technique that does not require knowledge of malicious code signatures.
So far, discussion has been focused on a particular type of code, namely “malicious code”, which performs unauthorized functions resulting in poor network performance. However, more generally, network performance may be negatively impacted by any type of code that utilizes network communication which negatively affects the performance of the network, whether introduced intentionally or unintentionally (for example, inadvertent results of a program due to poor programming). Some of the techniques used in the detection of malicious code (especially, for example, anomaly analysis), may be applied in attempting to detect the more general “aberrant” code. However, in order to determine what is and is not “aberrant”, one needs a “normal” network traffic reference point from which to compare existing network traffic. None of the above described techniques for use in detecting malicious code generate a baseline of “normal” network behavior from the network traffic itself that would allow detection of aberrant behavior.
Accordingly, a need also exists for a technique for identifying aberrant network traffic behavior from normal benign network traffic based only upon the network traffic itself.